1. Field of Invention
The invention relates generally to methods and apparatuses for implementing name services in distributed object systems. More particularly, the invention relates to methods and apparatuses for efficiently enabling both persistent and transient name services to be implemented within a distributed object system.
2. Description of Relevant Art
Name services are often implemented within distributed object systems to enable distributed objects to be readily identified. One type of a distributed object system which uses name services includes a distributed object system that is defined under the Common Object Request Broker Architecture (CORBA) specification. Distributed object systems which use name services may be in the context of an Object Request Broker (ORB) implemented under the CORBA specification from the OMG, Revision 2.0, dated July 1995, and updated July 1996, which is incorporated herein by reference in its entirety. Specifically, the "CosNaming" module of the CORBA Services specification, as specified in the CORBA specification from the OMG, may be used to implement name services.
A name service, which may be associated with a name server, is typically arranged such that when provided with a name, the name service associates the name with "something," e.g., an object, an object reference, or a property. The association of the name with an object, for example, may either be transient or persistent. For a transient name service, the association between a name and an object generally disappears once the program which uses the association between the name and the object terminates. Alternatively, for a persistent name service, the association between a name and an object is stored in a data file, and does not disappear once the program which associates the name with the object terminates. In general, the implementation of a name service often includes the implementation of a data structure such as a table to hold bindings between names and object references and, in some cases, properties. Such a data structure, in other words, may be used to associate names with object references, as well as properties.
FIG. 1 is a diagrammatic representation of an implementation of a name service in accordance with prior art. An implementation of a name service 100 includes a "main" table 104. Although main table 104 may take on a variety of different configurations, main table 104 is typically a look-up table, or a list, which associates names 108 in a name column 112 of main table 104 with pointers 116 in a pointer column 120 of main table 104. Pointers 116 in pointer column 120 identify, or reference, objects 124 which are associated with names 108. By way of example, name "X" 108a is associated with pointer "x.sub.p " 116a, which is a pointer to object 124a. As such, pointer "x.sub.p " 116a is essentially an object reference which identifies object 124a. Similarly, name "Y" 108b is associated with pointer "y.sub.p " 116b, which is a pointer to object 124b which, as shown, is a secondary list. Object 124b includes references to other objects, such as an object 128 which may also be a list. Object 124b may also include a reference 132 to main table 104.
The use of name service 100 enables a name, such as name "X" 108a, to be remembered, instead of pointer "x.sub.p " 116a, when access to object 124a is desired. By using a name as an index into main table 104 to identify an object, the overhead, and, hence, the complexity associated with locating objects can be reduced.
A look-up table which is included as a part of a name service, may either be transient or persistent. For a transient name service, local look-up tables, i.e., look-up tables which were created locally during a process, are temporarily stored in volatile memory, and are not stored into a file. As such, when a program which implements the local look-up tables terminates, the local look-up tables, in addition to information contained in local look-up tables, is destroyed. Alternatively, for a persistent name service, the local look-up tables are stored into files, as for example files on a non-volatile memory, such as a disk. Hence, data contained in look-up tables associated with a persistent name service is not destroyed when the program which implements the look-up tables is terminated.
A name may generally be expressed as an array of components, such as characters. In other words, although a name may be expressed as "abcd," when a name is to be processed, e.g., bound or resolved, the name is typically processed as an array of components [a, b, c, d]. When the name "abcd" is being "looked up," or resolved, using a name service, the components of the name are looked up sequentially. The first component of the name, i.e., "a," is resolved first, while the last component of the name, i.e., "d," is resolved last. FIG. 2 is a diagrammatic representation of a name service implementation which includes multiple look-up tables which may be used to identify a pointer to an object that is associated with and, hence, may be identified by name "abcd." A name service implementation 200 includes a main look-up table 204 which is used to associate a pointer "a.sub.p " 208 with a first component "a" of name "abcd."
Pointer "a.sub.p " 208 identifies a second look-up table 212 in which a second component "b" of name "abcd" may be found. Second component "b" is associated with a pointer "b.sub.p " 216 which identifies a third look-up table 220. Third look-up table 220 is used to find a third component "c" of name "abcd," which is associated with a pointer "c.sub.p " 224 that references a final look-up table 228. As shown, final look-up table 228 is the last in a chain of look-up tables associated with name service implementation 200. However, as will be appreciated by those skilled in the art, the number of look-up tables associated with a name is often dependent upon the number of components in the name.
Final look-up table 228 associates, e.g., binds, component "d" of name "abcd" with a pointer O.sub.ptr 232. In other words, when name "abcd" is traversed until only component "d" remains, component "d" may then be bound to pointer O.sub.ptr 232 which references an object 236 which is associated with the overall name "abcd." When name service 200 stores look-up tables, either in volatile memory or in non-volatile memory, tables 204, 212, 220, and 228 are all stored. As will be appreciated by those skilled in the art, typically, either all or none of tables 204,212, 220, and 228 are stored. When all tables are stored, by way of example, table 228 is either temporarily stored in volatile memory, such that table 228 is destroyed when the program that implements name service implementation 200 terminates, or table 228 is written into a file on a disk. In other words, for a transient name service, table 228 is stored in volatile memory, whereas for a persistent name service, table 228 may be stored on a disk. By analogy, tables 204, 212, and 220 are stored in the same manner.
Some name services may also store properties in look-up tables. For example, final look-up table 228 may include references to a property table which contains a property that is associated with name "abcd." A reference "prop" 240 associated with name "abcd" may identify a property table 244 which contains properties and may, in some instances, also include objects.
When look-up tables are stored on a non-volatile memory such as a disk, updating and accessing look-up tables, as for example to "look up" a name, is more complicated than updating and accessing look-up tables which are transiently stored in volatile memory. For instance, a table stored in volatile memory and its associated "image" on a non-volatile memory must be kept synchronized, i.e., current or up to date, thereby requiring additional logic. As such, the algorithms and code associated with the implementation of a persistent name service may be somewhat different and more involved, than the algorithms and code associated with a transient name service. A persistent name service often includes all the functionality of a transient name service, in addition to algorithms and code that are specifically associated with the storage of look-up tables. Typically, within a system which supports both a transient name service and a persistent name service, the algorithms associated with the transient name service and the algorithms associated with the persistent name service are often implemented as separate code sections.
In general, program code which is used to implement transient name services and persistent name services, within a given system, is relatively extensive. This is often due to the fact that for a system which includes the capability to implement both a transient name service and a persistent name service, the implementation of the transient name service and the implementation of the persistent name service generally involves the use of separate code sections. The use of separate code sections is often undesirable, as the resources used by the separate code sections may be significant. Further, since transient name services and persistent name services often include common functions and perform similar tasks, the use of separate code and different methods for processing transient name services and persistent name services may be inefficient. Therefore, what is desired is an efficient and compact method and apparatus for implementing both a transient name service and a persistent name service. Specifically, what is needed is an efficient method and apparatus for providing the capability to efficiently implement both a transient name service and a persistent name service within a single system.